fix(reassembly): a datagram too long for its length field never completes (#1585) - #1598

Please follow the guide below

• You will be asked some questions, please read them carefully and answer honestly

• Put an x into all the boxes [ ] relevant to your pull request (like that [x])

• Use Preview tab to see how your pull request will actually look like

• Searched for similar pull requests

• Followed the coding style (make pylint, make mypy, make isort)

• make test passes, and a test case covers the change

• Added a changelog entry under docs/source/changelog/ and regenerated CHANGELOG.md, if the change is user-visible — N/A — centralised in docs(changelog): shared 1.5.0 changelog — long-lived, merges last (#610, #616, #617, #618, #620) #657

What is the purpose of your pull request?

Tick the commit type your subject line carries.

• fix — corrects a defect
• feat — adds a feature
• perf — changes performance, not behaviour
• refactor — changes neither behaviour nor performance
• test — tests only
• docs — documentation only
• ci — workflows or build tooling
• release — bumps the version or rolls up a distribution
• chore — anything else

Description of your pull request and other information

Closes #1585. The code change is in pcapkit/foundation/reassembly/ip.py and ipv6.py; the docs under docs/source/pcapkit/foundation/reassembly/ip/ and the Datagram.conflict comment are brought in line.

• Length bound. IP._is_complete now bounds a datagram at 65,535 octets with its header, as the new IP._header_overhead counts it. IPv4's Total Length counts the whole header. IPv6's Payload Length counts every header except the fixed 40 octets, so ipv6.py overrides the hook. The issue's case 3c (20 + 65,523) now reads PARTIAL with every octet still reported. IPv6 with no extension header still completes at 65,535 octets of data.
• Total Length 0 declares no length (fix(reassembly): IPv4 reassembly leaves a TSO datagram (total_length 0) incomplete #1555). If such a datagram is too long with its header, the buffer grows past 65,535 octets, and that lifts the bound. The 1555 and 1565 TSO pins are unchanged.
• _detect_conflicts docstring. It now says that octets in an unmarked partial block are deliberately not compared (fix(reassembly): IPv6 reassembly zero-fills a snaplen-cut non-final fragment and reports it COMPLETE #1567). A new test pins this. The Datagram.conflict comment and the conflict notes in ipv4.rst and ipv6.rst had the same stale claim, and now say the same.
• Docs. ip/index.rst lists the bound, with the Total Length 0 exemption, as a third departure from RFC 791.
• Changed pin. One fix(reassembly): IPv4 reassembly raises IndexError for a fragment reaching octet 65,528 #1565 test asserted that an IPv4 final fragment at offset 65,528 completes. That is the defect, because 20 + 65,529 > 65,535, so the test now runs on IPv6 only.

The default, dpkt and scapy engines agree on crafted IPv4/IPv6 captures. Sample-capture reassembly is byte-identical to main: 7,998 rows across those engines, in both modes.